The USB specification up to and including revision 2.0 was intended to facilitate the interoperation of devices from different vendors in an open architecture. USB 2.0 data is encoded using differential signalling (viz. in which two wires transfer the information) in the form of the difference between the signal levels of those two wires. The USB 2.0 specification is intended as an enhancement to the PC architecture, spanning portable, desktop and home environments.
However, USB was user focussed so the USB 2.0 specification lacked a mechanism for synchronising devices to any great precision. Several proposals attempted to address this and other deficiencies. For example, U.S. Pat. No. 6,343,364 (Leydier et al.) discloses an example of frequency locking to USB traffic, which is directed toward a smart card reader. This document teaches a local, free-running clock that is compared to USB SYNC and packet ID streams; its period is updated to match this frequency, resulting in a local clock with a nominal frequency of 1.5 MHz. This provides a degree of synchronization sufficient to read smart card information into a host PC but, as this approach is directed to a smart card reader, inter-device synchronization is not addressed.
WO 2007/092997 (Foster et al.) discloses a synchronized USB device that allows the generation of accurate clock frequencies on board the USB device regardless of the accuracy of the clock in the Host PC. The USB SOF packet is decoded by the USB device, and treated as a clock carrier signal instead of acting as a clock reference.
The carrier signal, once decoded from the USB traffic, is combined with a scaling factor to generate synchronization information and hence to synthesize a local clock signal with precise control of the clock frequency. In this way, the frequency of the local clock signal can be more accurate than the somewhat ambiguous frequency of the carrier signal.
This arrangement is said to be able to produce a local clock signal to arbitrarily high frequencies, such as a clock frequency of tens of megahertz, and thus to ensure that the local clock of each device connected to a given USB is synchronized in frequency. U.S. application Ser. No. 10/620,769 also teaches a method and apparatus to further synchronize multiple local clocks in phase by measurement of signal propagation time from the host to each device and provision of clock phase compensation on each of the USB devices.
U.S. patent application Ser. No. 12/279,328 (Foster et. al.) teaches synchronisation of the local clocks of a plurality of USB devices to a timebase received from another interface. In one embodiment, a USB device contains a local clock that is synchronised to an externally provided time signature across Ethernet using the IEEE-1588 protocol. In yet another embodiment the USB device's clock is synchronised to a timebase derived from a Global Positioning System (GPS) synchronised clock.
All of the above systems work within the bounds of conventional USB 2.0 and as such are limited in several areas. USB 2.0 is limited in range by the device response timeout. This is the window of time that the USB Host Controller allocates for receipt of a signal from a given USB device in response to a request from said USB Host Controller. The physical reach of USB 2.0 is therefore approximately 25 m.
The USB 3.0 specification was released in November 2008 and is also focussed on consumer applications. The USB 3.0 specification makes significant changes to the architecture of USB. In particular, the background art synchronisation schemes discussed above will not work with the newer 5 Gb/s protocol (termed ‘SuperSpeed USB’) because it does away with the broadcast mechanism for SOF packets.
USB 3.0 defines two parallel and independent USB busses on the same connection cable. Firstly, the USB 2.0 bus remains unchanged (for backward compatibility) and offers Low Speed (1.5 Mb/s), Full Speed (12 Mb/s) and High Speed (480 Mb/s) protocols. The second bus—for 5 Gb/s traffic—provides the SuperSpeed USB. These busses operate independently, except that operation of the busses to a given USB device is mutually exclusive. That is, if a SuperSpeed connection is possible, then the USB 2.0 bus in disconnected to that device.
The dual-bus architecture of USB 3.0 is depicted schematically at 10 in FIG. 1. Personal Computer 12, containing USB Host Controller 14, is connected to USB 3.0 Hub 16 by first USB 3.0-compliant cable 18; USB 3.0 device 20 is connected to a downstream port 22 of USB 3.0 Hub 16 by second USB 3.0-compliant cable 24.
USB Host Controller 14 contains both a USB 2.0 Host 26 and a SuperSpeed Host 28. These two hosts 26, 28 are independent of one another, and each host 26, 28 is capable of connecting up to 127 devices (including hubs). USB 3.0-compliant cables are compound cables, containing a USB 2.0-compliant cable and a series of shielded conductors capable of transmitting SuperSpeed signals. Hence, USB 3.0-compliant cable 18 comprises USB 2.0-compliant cable 30 and shielded conductors 32.
USB 3.0 Hub 16 contains both a USB 2.0 Hub function 34 and a SuperSpeed Hub function 36, each connected directly to its respective Host 26, 28 by compound cable 18. USB 3.0 device 20 contains both a USB 2.0 device function 38 and a SuperSpeed device function 40, each connected back to its respective hub function 34, 36 of USB 3.0 Hub 16 by compound cable 24.
At enumeration of USB 3.0 device 20, SuperSpeed Host 28 checks for the presence of a SuperSpeed device function (40). If a SuperSpeed device is found, then a connection is established. If a SuperSpeed device is not found (as in the case where only a USB 2.0 device is connected to port 22), then the USB 2.0 Host 26 checks for the presence of a USB 2.0 device function (38) at device 20. Once the Host Controller 14 determines which device function is connected, it tells the USB 3.0 Hub 16 to only enable communication for downstream port 22 corresponding to whether the USB 2.0 device function 38 or SuperSpeed device function 40 is attached. This means that only one of the two parallel busses is in operation at any one time to an end device such as USB 3.0 device 20.
Furthermore, SuperSpeed USB has a different architecture from that of the USB 2.0 bus. Very high speed communication systems consume large amounts of power owing to high bit rates. A design requirement of SuperSpeed USB was lower power consumption, to extend the battery life of user devices. This has resulted in a change from the previous broadcast design of the USB 2.0: SuperSpeed is not a broadcast bus, but rather directs communication packets to a specific node in the system and shuts down communication on idle links.
This significantly affects any extension of the synchronisation schemes of, for example, U.S. patent application Ser. No. 12/279,328, whose method and apparatus for synchronising devices is based on a broadcast clock carrier signal that is delivered to each device on the bus, which is unsuitable in SuperSpeed USB.
A SuperSpeed Hub function acts as a device to the host (or upstream port) and as a host to the device (or downstream port). This means that the SuperSpeed Hub function acts to buffer and schedule transactions on its downstream ports rather than merely acting as a repeater. Similarly, the SuperSpeed Hub function does so with scheduling transmissions on the upstream port. A heavily burdened Hub function can therefore add significant non-deterministic delays in packet transmission through the system. This also precludes the use of USB 2.0 synchronisation schemes such as that of U.S. patent application Ser. No. 12/279,328 from operating on SuperSpeed USB.
The crude Isochronous synchronisation of USB 2.0 has been significantly improved in the USB 3.0 specification. Opening an Isochronous communication pipe between a Host Controller and a USB device guarantees a fixed bandwidth allocation in each Service Interval for the communication pipe. The Isochronous Protocol of USB 3.0 contains a so-called Isochronous Timestamp Packet (ITP), which is sent at somewhat regular intervals to each Isochronous Endpoint and which contains a timestamp of the beginning of ITP transmission by the USB Host Physical Layer (Phy) in the time domain of the Host Controller. The Isochronous Timestamp Packet is accurate to about 25 ns. SuperSpeed USB shuts down idle links to conserve power, but links must be active in order to receive an Isochronous Timestamp Packet. The Host Controller must therefore guarantee that all links to a device are in full active mode (termed power state U0) before transmission of the Isochronous Timestamp Packet.
Unfortunately the Isochronous Timestamp packet can be delayed in propagation down the USB network. USB 3.0 also does not provide a way of determining the propagation time of packets in SuperSpeed USB and hence no way of accurately knowing the phase relationship between time domains on different USB devices. Phase differences of several hundred nanoseconds are expected to be a best case scenario with SuperSpeed USB making it impractical for instrumentation or other precision timing requirements.
U.S. Pat. No. 5,566,180 (Eidson et al.) discloses a method of synchronising clocks in which a series of devices on a communication network transmit their local time to each other and network propagation time is determined by the ensemble of messages. Further disclosures by Eidson (U.S. Pat. Nos. 6,278,710, 6,665,316, 6,741,952 and 7,251,199) extend this concept but merely work toward a synchronisation scheme in which a constant stream of synchronising messages are transferred between each of the nodes of a distributed instrument network via Ethernet. This continual messaging consumes bandwidth and limits the accuracy of the possible synchronisation to several hundred nano-seconds in a point-to-point arrangement and substantially lower accuracy (typically micro-seconds) in a conventional switched subnet.
It should be understood that the terms ‘clock signals’ and ‘synchronisation’ in this disclosure are used to refer to clock signals, trigger signals, delay compensation information and propagation time measurement messages. It should also be understood that a ‘notion of time’ in this disclosure is used to denote an epoch or ‘real time’ and can also be used to refer to the combination of a clock signal and an associated epoch.